Bug 550486 - KDE 4 Power Management System Settings CPU frequency scaling unsupported
Summary: KDE 4 Power Management System Settings CPU frequency scaling unsupported
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Fedora
Classification: Fedora
Component: kdebase-workspace
Version: 12
Hardware: i686
OS: Linux
low
medium
Target Milestone: ---
Assignee: Than Ngo
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
: 562542 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2009-12-25 14:30 UTC by lanx
Modified: 2010-04-11 10:23 UTC (History)
19 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2010-03-03 16:49:19 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)
KDE 4 Power Management System Settings on F12 and Kubuntu 9.10 (115.39 KB, image/jpeg)
2009-12-25 14:30 UTC, lanx
no flags Details

Description lanx 2009-12-25 14:30:04 UTC
Created attachment 380310 [details]
KDE 4 Power Management System Settings on F12 and Kubuntu 9.10

I have installed F12 (no upgrade, just new install) and kde 4 power management in system settings says that CPU frequency scaling is not supported.

Previously on F10 with Guidance Power Manager it was working fine,
just in case I have checked the latest kubuntu and in kubuntu it works fine.

Cpuspeed is working and I can manually change CPU frequency with cpufreq-set.

Hardware details:
Toshiba L40-14F laptop.

cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_frequencies
1467000 1067000 800000 
cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_governors
ondemand userspace performance

cat /proc/cpuinfo
processor	: 0
vendor_id	: GenuineIntel
cpu family	: 6
model		: 15
model name	: Intel(R) Pentium(R) Dual  CPU  T2310  @ 1.46GHz
stepping	: 13
cpu MHz		: 800.000
cache size	: 1024 KB
physical id	: 0
siblings	: 2
core id		: 0
cpu cores	: 2
apicid		: 0
initial apicid	: 0
fdiv_bug	: no
hlt_bug		: no
f00f_bug	: no
coma_bug	: no
fpu		: yes
fpu_exception	: yes
cpuid level	: 10
wp		: yes
flags		: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx lm constant_tsc arch_perfmon pebs bts pni dtes64 monitor ds_cpl est tm2 ssse3 cx16 xtpr pdcm lahf_lm
bogomips	: 2925.94
clflush size	: 64
power management:

processor	: 1
vendor_id	: GenuineIntel
cpu family	: 6
model		: 15
model name	: Intel(R) Pentium(R) Dual  CPU  T2310  @ 1.46GHz
stepping	: 13
cpu MHz		: 800.000
cache size	: 1024 KB
physical id	: 0
siblings	: 2
core id		: 1
cpu cores	: 2
apicid		: 1
initial apicid	: 1
fdiv_bug	: no
hlt_bug		: no
f00f_bug	: no
coma_bug	: no
fpu		: yes
fpu_exception	: yes
cpuid level	: 10
wp		: yes
flags		: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx lm constant_tsc arch_perfmon pebs bts pni dtes64 monitor ds_cpl est tm2 ssse3 cx16 xtpr pdcm lahf_lm
bogomips	: 2925.86
clflush size	: 64
power management:

Comment 1 Rex Dieter 2009-12-25 14:56:51 UTC
Upstream please.

If it matters any, many experts advise using the default cpu scaling policy for best results,
http://www.codon.org.uk/~mjg59/power/good_practices.html

Comment 2 Rex Dieter 2009-12-25 15:12:37 UTC
ok, nevermind about upstream, does appear to be fedora specific (if I take the second ubuntu screenshot to imply it working there).

Comment 3 Rex Dieter 2009-12-25 17:27:46 UTC
solid-powermanagement query cpufreq

please.  Seems not to work for me on f12/kde-4.3.85,


$ solid-powermanagement query cpufreq
solid-powermanagement(7283)/kdecore (KSycoca) KSycocaPrivate::openDatabase: Trying to open ksycoca from  "/var/tmp/kdecache-rdieter1/ksycoca4"
solid-powermanagement(7283)/kdecore (KLibrary) kde4Factory: The library "/usr/lib64/kde4/solid_hal_power.so" does not offer a qt_plugin_instance function.

Comment 4 lanx 2009-12-26 22:42:02 UTC
solid-powermanagement query cpufreq runs and shows no output.
just in case I have downloaded F11 Kde live and it shows available governors.

I agree with experts, but it's about principles :)
if something's broken must be fixed.

Comment 5 Steven M. Parrish 2010-01-12 12:01:40 UTC
This bug has been triaged

Steven M. Parrish
KDE & Packagekit Triager 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

Comment 6 Rex Dieter 2010-02-17 13:56:20 UTC
*** Bug 562542 has been marked as a duplicate of this bug. ***

Comment 7 Maxim Burgerhout 2010-02-28 13:55:10 UTC
Bug's still present after recent push to KDE 4.4.0 on Intel Core2Duo P8400, which definitely supports scaling.

Comment 8 Uwe Kaiser 2010-03-03 07:52:56 UTC
I found that since version 0.5.13-6 fedora compiles hal with the --without-cpufreq option.

http://cvs.fedoraproject.org/viewvc/rpms/hal/F-12/hal.spec?revision=1.209&view=markup

So no hald-addon-cpufreq in hal, no scaling capability in KDE

Regards

Comment 9 Kevin Kofler 2010-03-03 07:56:12 UTC
=> Reassigning to HAL.

Comment 10 Kevin Kofler 2010-03-03 07:58:04 UTC
We need cpufreq reenabled in HAL, KDE still needs this!

Comment 11 Richard Hughes 2010-03-03 09:27:23 UTC
(In reply to comment #10)
> We need cpufreq reenabled in HAL, KDE still needs this!    

No, HAL upstream is dead, and we're slowly throttling back on supported features. In F14 HAL should cease to exist at all.

If you're changing the cpufreq governor nowadays as part of a power-saving scheme, then you're really doing something terribly wrong.

Comment 12 Kevin Kofler 2010-03-03 09:38:50 UTC
> No, HAL upstream is dead

That's an exaggeration. It's in maintenance mode. A truly dead upstream looks different (there are no commits at all, just a years-old tarball).

> and we're slowly throttling back on supported features.

I don't think it's acceptable that you're disabling HAL features without even talking to us KDE folks about it, KDE being the biggest remaining user of HAL. In fact, we only noticed KDE is missing a feature and had no idea why until somebody traced it down to the feature being disabled in HAL.

> In F14 HAL should cease to exist at all.

"Should", sure, are you doing the work on porting KDE away from it? Thought so. KDE upstream has just started working into that direction as part of some major Solid reorganizations, this may or may not be ready in 4.5 (which is what F14 will presumably ship).

> If you're changing the cpufreq governor nowadays as part of a power-saving
> scheme, then you're really doing something terribly wrong.

KDE upstream does not agree with that assessment, and I don't see why we are, and should in your opinion keep, shipping a crippled version of their software just because you have a different opinion about that.

Comment 13 Chris Smart 2010-03-03 09:51:56 UTC
(In reply to comment #11)
> If you're changing the cpufreq governor nowadays as part of a power-saving
> scheme, then you're really doing something terribly wrong.    

Governor, sure. Everyone should really be using ondemand. However, what would be nice is to be able to actually *turn it on* under a KDE based system, not only that, but to perhaps disable it under certain circumstances.

Currently under a fresh Fedora KDE 4.4 install my laptop does not enable any CPU scaling at all. I can't enable it under KDE because it doesn't work..

Of course, I can control this by the command line, but it would still be nice to have it working under KDE.

-c

Comment 14 Richard Hughes 2010-03-03 10:02:48 UTC
(In reply to comment #12)
> I don't think it's acceptable that you're disabling HAL features without even
> talking to us KDE folks about it, KDE being the biggest remaining user of HAL.
> In fact, we only noticed KDE is missing a feature and had no idea why until
> somebody traced it down to the feature being disabled in HAL.

Sure, and if we enable the feature, and somebody reports bugs on it, who gets to fix them? Me.

> "Should", sure, are you doing the work on porting KDE away from it? Thought so.
> KDE upstream has just started working into that direction as part of some major
> Solid reorganizations, this may or may not be ready in 4.5 (which is what F14
> will presumably ship).

I'm not sure why I should be doing any KDE work. It's been known for a couple of years now that HAL is being deprecated.

> KDE upstream does not agree with that assessment, and I don't see why we are,
> and should in your opinion keep, shipping a crippled version of their software
> just because you have a different opinion about that.    

Well, I seem to have the same opinion as the kernel guys who actually add the functionality to the kernel. Please read http://www.codon.org.uk/~mjg59/power/good_practices.html

Comment 15 Richard Hughes 2010-03-03 10:03:45 UTC
(In reply to comment #13)
> Currently under a fresh Fedora KDE 4.4 install my laptop does not enable any
> CPU scaling at all. I can't enable it under KDE because it doesn't work..

It should be doing ondemand by default. If not, it's a kernel bug.

Comment 16 Rex Dieter 2010-03-03 16:32:32 UTC
After discussing the issue a bit with hughsie and some kernel folks, here's the deal:

it was agreed (speaking for myself anyway) that fedora's default ondemand governor is very good, and not using it is generally a bad idea.

Further, to re-enforce comment #15 , if the ondemand doesn't work well for you, it is considered a kernel bug, and can/should be fixed there.

Comment 17 Rex Dieter 2010-03-03 16:49:19 UTC
Now, if after all that anyone is still not convinced to simply use the ondemand default, I'm willing to spin up some unofficial hal rpms re-enabing this feature.

Comment 18 Rex Dieter 2010-03-08 15:04:54 UTC
See also,
Summary: powerdevil: Remove CPU frequency scaling interfaces
http://reviewboard.kde.org/r/3206/

Comment 19 Joshua Covington 2010-04-11 10:23:31 UTC
After reading the following:
http://www.codon.org.uk/~mjg59/power/good_practices.html
http://reviewboard.kde.org/r/3206/  
I have to agree that there are legitimate reasons to _disable_ the CPU frequency scalling support in KDE 4.4.x.

However my laptop has a 3+ year old AMD turion 2.0 GHz processor limited to c1 state. On the top of this, the mobo has also come to its limits. 

Nowadays flash is _sadly_ one of the most widely used applications on the internet. And it's quite a big cpu hog. Therefore I frequently reach temperatures above 90C which are the bareable limit for the cpu (the not so good xorg-x11-drv-ati is also to mention here). These make the cpu downclock in oder to save it. Therefore I frequently come across situations where I can justify the use of the powersave governor. This is also described as

"Some systems have poor cooling mechanisms and so may overheat under heavy CPU load. One common attempt to work around this is to limit the maximum speed of the processor in order to reduce its heat output. However, this prevents the processor from running at full speed even when it's not in danger of overheating. This will result in it taking longer for the CPU to enter idle states, ironically resulting in it becoming hotter than neccesary and consuming more energy.

Summary: If users need to perform thermal management of their systems, write an application that monitors the temperature and limits the CPU speed appropriately. Don't attempt to perform thermal management by using power management functionality to statically limit the processor frequency. " in http://www.codon.org.uk/~mjg59/power/good_practices.html

So, what should I do?

Can someone made a separate hal-old-laptops-package (with cpu-frequency-scalling enabled) that is to be installed only on laptops which do need this cpu scaling. Maybe this way the current situation can be circumvented without the need to recompile the hal everytime.

I know this is not a perfect solution but there are some rare cases where this support is still needed.


Note You need to log in before you can comment on or make changes to this bug.